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ABSTRACT 

Sorting up electronic Business-to-Busincss relaaoaship? is time- 
consuming and costly. It ha$ "been cased to a certain extent by 
standards such, as RosetlaNet> which use XML and XML Schema 
technologies to define standardised syntax of messages used in in- 
teractions. However, this standardisation has necessarily main- 
tained atnttfi rlcribiliry to allow companies with different internal 
processes to comply with the standard. Pinthcnnore, the standard 
is syntactic, rather than semantic. Semantic constraints on interac- 
tions are currently represented inforxnally. 

In this paper, wc describe an applicsdou of Semantic "Web tech- 
nology to enhance RoBdmNert and further reduce cost and rune. 
Businesses can represent the possible ways they are able to mieract 
as semantic and syntactic constraints. Two businesses can determ- 
ine if they are able *o interact without altering their ousiness process 
by sharing constraint and finding if the overall set is satisfiable. 
If it is not, They em use the data lo determine what changes need 
to be made u> iheir business processes. They can also nee the other 
business' constraints to verify or generate documents which meet 
the constraints, and so are u$able by the other "business. The sys- 
tem integrates with current RosettaNeL standards and tools Through 
the use of a, translation suite able to Transform XML Schema into 
DAML+OIL and XML into RDF. 

Categories and Subject Descriptors 

E.1 [Data]: Data Structures; L2.4 [Computing Methodologies]: 
Artificial Intelligence-^ Knowledge Repr&fentmipn Formalisms and 
Methods; TA [Computer Application*]: Ajdminigtratiw Data Pro- 
cessing 

General Terms 

Languages, Standardization 

Keywords 

Semantic Web, Business-to-Business, Interoperability, DAML+OD-, 
XML Schema 

1. INTRODUCTION 

Despite the bursting of the dot com bubble, electronic commerce 
continues to be an increasingly irnponant aspect of the economy. 
To the general public, the most visible face is the increasing number 

Copy* Igftt is Held by lac atancE/owiicnls). 
WWW2003, May 20-24, 2003, Bwhpcst, Hungary. 
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of Bosiness-to-Consumcr interactions available via ihe web. How- 
ever, the majority of economic transactions occur between busi- 
nesses, making the Busmcsa-nvBraincss (B2B) aspect of electronic 
commerce » wfinificantly uira«r market- Historically, business rela- 
tionship 6 have been long-term- Wfeen such a relationship has been 
established, EDI (Electronic Data Interchange) technology can be 
used to automate certain straightforward interactions between the 
business partners - for example, the purchase of goods ai a pre- 
agreed price, and the delivery of them. Setting up the EDI sys- 
tem requires ihc two parties to agree on interactioft |*rotocols and 
message formats, and to implement a messaging system that meets 
these agr eem ents - often over a Virtual Private Network. This can 
be a nme-consirmfug and costly process. 

RosensNet [15] is an industrial consortium which aims to make 
this process cheaper and more sti^^Tfcovard, by using XML [3] 
messaging technology transported over ihe World Wide Web. It 
doe* this by standardising the format, content and sequence of mes- 
sages between partners ftr a variety of possible infractions which 
companies can use m BZB relationships. Hence, companies do 
not need to go through a lengthy negotiation to specify the way 
in which they are going tp hueracr. mstead, they simply need to 
agree on which standard interaction to use. Standardisation also 
speeds up the development process, as products such as WcbMeth- 
ods Trading Networks Server include software libraries and XML 
templates supping RoaettaNet mtemctions. 

Xtus standardisation effort ba$ substantially reduced the cost and 
time of settingup aBZB relationship. However, because it is based 
on XML technology, the tools provided axe primarily syntactic. In 
ibis paper, we describe an application of Semantic Web technology 
to enhance RosetraNet and farther reduce cost and time. Businesses 
can represent the possible ways they are able to interact as semantic 
constraints. Two businesses can determine if they sr& able to inter- 
act without altering their business process by sharing constraints, 
and JWine if the overall set is eausfiabla. They can use the other 
business' constraints to generate documents which meet the con- 
straints, and so ate useable by the other business. 

This application is evolutionary, rather than revolutionary. It ac- 
cepts existing RosettaNct design decisions snd tools as they cur- 
rently are, nrthcx than requiring modification or re-design of these. 
As a result of this* it is mens likely to be rapidly accepted and 
adopted by the current B2B developer cononruxity This means 
it must use Semantic Web technology in a relatively conservative 
way. We believe that by doing this the developer cornnrunifcy will 
become more familiar with the basic ideas, allowing more radical 
approaches to be taken in the future. 
The stoic Lure of this paper is as follows. In section 2 wc give 
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aa overview ofKosettaNct and present some of the problems thai 
implements counter when Ihey deploy RcsctlaNet solutions, la 
action 3 we describe the r^ astern which aims ai solving these 
problems with Semantic Web technique In particular we describe 
the too main comments or this system, the Nile translate suite 
and Ihe Ctonsiiaini Knowledge Base, m section 4 w describe a 
typical use of the Nile system and show how it solves the problems 
exposed in section 2. We then discuss related work (section 5) and 
we conclude prcsennnE o^r roruxc work intentions (section 6), 

2, RGSETTANET NOW 

KoaeitaNct standards have gone a long way to ease the process ef 
setting no and executing lone-term B2B relationships via the web- 
Thc key* concept used lo do this is the Partner Interface Process 
(PEP) PIPs are used to define standard ways of interacting between 
companies to carry out a specified task. They define the aspects 
of a business process which are common to the two parties, but 
place xift constraints on how the internal processes implement these 
common aspects. A PIP specification defines the flow of message 
document which will take place during an interaction, and also 
specifies the format of the messages. A message tbrrnat is defmcd 
through 'message guidelines " docujncriiarion, and an XML T3TD 
describing the syntacuc structure a message should have. 

Hence,, in theory* all businesses have to do to set up a new part- 
nership is to agree on which PTPs to use, and implement the PIP 3 
accor ding to thctf spetincatiora. However* as tfrrererrt busmesses 
can have different back-end processes, some flexibility within the 
standards is necessary io enable all business in satisfy it. Per 
example one business may normatty re p resent dates on invoices 
using ISO 5601 format (yVyY-MM-DD) while another way iise 
tjk common practice (DD/MM/YTTYY)- One business may expect 
the account details of Hie buyer on an invoice, while another may 
not. To allow dirrerences such as these, PIP defmitions often make 
use of generic datatypes (such as strings or integers) and include 
optional fields or fields with unbounded cardinalities. As a result 
of thi S flexibility, there is no guarantee that two RosettaN ct compli- 
ant ttunpKnies will be able to ccmrrrunicate with each other: differ- 
ent business practice* or back-end systems may impose different 
conditions on the presence of some infrmnarion or on its format 
fe ccau se of this, it is necessary to reconcile tbe different processes 
used by two uompanies which intend to interact via "RosertaNet. 
There is some flexibility in the way in which a PEP can be imple- 
mented, and it is necessary that irxterachng parties agree as to the 
specific implementation chosen. This process of reconciliation is 
ainently carded out off-line, using spreadsheets to domirnenr de- 
cisions. Developers then implement these decisions as they encode 
the PIFs. This can be a very tune-consuming process meaning that 
ii can take many months to create a new RosertaNet parrneiship. 
Hence interoperability, one of the advantages of standardisation, i$ 
sacrificed in favour of flexibility. 

RpsetraNet arc currently developing Next Generation MPs □ in 
an ancmpt to produce specifications than are more formal than the 
message guidelines used in the cinrent standards. For each Next 
Generation PIP, RosettaNct specifics a UML class diagram [131 
and XML Schema* [17, 2] mat replace the XML DTDs. The UML 
class diagram defines the business object - such as financial docu- 
ments or purchase requests - that are used in the PIP- To encourage 
reuse across FD?s a RosertaNet defines a domain model, i.e. a set of 
base classes that can be reused or subclassed in the UML class dia- 
grams. The XML Schemas define what makes an XML docurnent 
a syntactically valid PIP document. XML Schemas are currently 
defined manually from the UML class diagram. 

Having an explicit maehme-readablc representation of the con- 



straints imposed by a PIP makes setting up a parmerstep quicker 
and easier. Reconciliation can take place by agreeing a set of fur- 
ther constraints on each XML Schema within the FTP- Furthermore, 
having the agreed document structure specif in this format al- 
lows the developers to use tools such as Counvo f 5] to rapidly auto- 
mate the process of document generstioji. 
Hcrwevcr, this approach b*£ several diaadvanraees: 

• The constraints that XML Schema are able to represent are 
mainly constraint on the syntax, not ihe semantics, of doc- 
uments. This means certain constraints which appear in a 
prp ^ccirkation which cannot be represented in the XML 
Schema. A typical example of this sort of conslraint is a de- 
pendency between fields, for instance the presence of a field 
implying a cardinality constraint on another field. As an ex- 
periment, RosertaNet is using OCL [12] to represent such 
cxrastraints in the definition of Next Generation PTPs. Cur- 
rently, these are documented as comments within the XML 
Schemas. 

» As seen earlier, a company's business processes impose con- 
straints en 1he deployment of PIPs. Some of these constraints 
Me of syntactic nature and can usually be captured in an 
XML Schema - which must be more specific than the PlP 
XML Schema, Some may be or semantic nature and so can- 
not be expressed in XML Schema Companies deploying 
RosertaNet PIPs usually document these constraints in the 
form of spreadsheets that are manually created tor the pur- 
pose alone deployment- 

• Additional constraints impo sed during the reconciliation pro- 
cess may also be semantic in namre s and therefore cannot 
ainently be represented m a niachme-marlable format 

• The same business object class may appear in several docu- 
ments exchanged during *n imeraction. Constraints imposed 
on this class should he applied to all documents thai use this 
class (either directly or through a subclass). Currendy, this 
will mean editing all of the associated schema to include the 
constraint. This imposes an iinnecessary burden on the de- 
velopers, and can potentially pose rnamtenarice problems, 

• rvmct mmig pn a rwsiness object class depend on Ihe context 
— i.e. the specific deployment scenario - this class is n$ed. 
We have identified that the deployment context is a function 
of: 

1. the PIP Document being used; 

2. the Trading partner erne is doing business with and whether 
they act as a buyer or seller; 

3. the business process being used(drScrcnL business pro- 
cesses using a given PIP with a given trading partner 
may impose Afferent constraints because of business 
requirements of back-end systems.)- 

The Next Generation PIP cannot adequately manage Che ap- 
plication of different constraints in different circumstances. 
Currently, the developers would have to manually aggreg- 
ate the constraints corresponding to a deployment context 
into refined XML Schemas and other informal docirrneirrs - 
when XML Schema is not expressive enough. This is ineffi- 
cient and could pose mairrtenance problems. Moreover, sin ee 
these constraints are not captured in a formal and systematic 
way, seme knowledge could be lost from a deployment to the 
next. 
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• The same consijainr may apply to a certain cl*$s af partners. 
Formstance, a back-end system conld impose a. c ccisKaint an 
a Tax class for all its European partners. Simile il should 
be possible to apply constat on classes of PIP dgcumeaits 
(c.ff. Invoicing documenis) or business processes (e.g. Elec- 
tronic component purchasing). 

In This piper, we present a way of overcoming these shoatfells. 
We present a system tfuu can Tnanage the relationship between a 
business *md sevcxal different paimers by formally capturing the 
constrtints oo RosertaNet deployments. It is able to antomarically 
detect if interactions ate possible with a new poremiat partner, and 
can support the reconciliation process by allowing implementation 
of both syntactic and semantic constraints agreed by th= partners. 
The system is aitfe to determine exactly which amstmmts to apply 
depending on the deployment context, and is able to automatically 
jencraie an appropriate schema to ronmnmicate with the business 
partner. 

3. THE NILE SYSTEM: INTRODUCING SE- 
MANTICS 

We have developed the Nile system to case the B2B mtegta- 
tion process, and to overcome she shortfalls ofRosertaKet outlined 
above. In this system, we rely on XML Schema to express the syn- 
tactic constraint? arid on DAML+OIL [9] to express the semantic 
cOflsti amtB Our approach makes use of XML Schemata define and 
validate the synlax of PIP documents (in particular XML Schema 
can check the ordering of fields withing a document and the format 
of datatypes [2]). It also makes use of DAML+OIL to define se- 
pianiic constraints. As we will show in the remainder of ttda paper, 
we believe that DAML+OIL can be used to model: 

1 . the "business object class hierarchies and their athibnres (or 
properties, in Semantic Web terms); 

2. the semantic constraints on business objects form the PIP 
defiintions (currently m^wtedlcd in OCL) ; 

3. rhe notion of deployment context; 

4. the additional semantic constrainls imposed by a business 
with respect to a deployment context 

To our knowledge current B2B standards do noi make we of 
DaML-kOIL. However they often rely on XML Schema to define 
the syntax of the doevmenrg being exchanged. There is hence a 
need to lift the B2B schema* to an ontology language, 

Nile consists of three key technology components 

• The XML Schema to DAML+OIL translation rool which con- 
verts XML S enemas into DAML+OIL class hierarchies and 
constraints; 

• The Constraint iCnnwledfie Base, This is a structured know- 
ledge base, in DAML+OIL, which describes the constraints 
that a busyness places on business object classes and m what 
deployment context these constraints apply. The Nile Con- 
straint Editor manipulates the Constraint Knowledge Base 
and it allows a user: 

1, to populate the deployment context ontology, Le. to 
define the instances and classes representing the set of 
PIP documents, partners and business processes which 
characterise abesmess' feoscttaNet deployments; 



2. tv browse me business object class ddtdtion* in. the 
DAML+OIL knowledge base; 

3. to create, modify and browse constraints on business 
objects in a given deployment context. 

The Nile Constraint Fdiror provides a set of coratraint tem- 
plates of the tonne typically encountered in Ro^taNet im- 
plementations. A business will create cor&waifirs using these 
templates. 

• The XML document Validator. This set of generic tools is 
used for translating documents from Ihe 'syntactic' world of 
XML into the 'semantic" world of RDF [10]: Specifically, 
it's fnnctionality allows: 

1. A 'best effort' translation of DAML+OIL class hier- 
ai-cnies and constraints back into XML Schema; 

2. XML documents to be translated into RDF- 

3-1 XML Schema to DAML+OIL mapping topi 

Many XML "based applicabons, like RosetiaNct, would benefit 
r«m rich iramajntic modelling capabilities. "While XML Schema 
covert some simple data modeling needs [1 1], we would like to get 
access to more general and powerful techniques. 

XML defines a transfer syntax, for tree-strucwred documents. 
XML Schema definitions holds the declarations tor validating XML 
instance documents. These declarations arc syntactic constraints on 
what make valid XML document. 

In the SenMntic Web domain. RDF 110] motels data in me form 
of directed labeled graphs and is layered or top of XML for seri- 
alization. As pointed out in [14], this choice of a different data 
model makes rich semantic descriptions and infcrencing are out of 
reach for XML applications- In particular, we would like to bene- 
fit from DAML+OIL [9] modeling capabilities in B2B applications 
such as RosetteNei since it offer* an expressive logic while keeping 
effidemrowoning possible 

The XML Schema ro DAML+OIL rriappingtool generates fipAML+DEL 
ontology from an XML Schema type hierarchy. The purpose of 
such a tool is to lift XML Schema to the level of an ontoJogy- 
Tt creates a skeleton ontology which can be extended with any 
DAML+ODL editor (such as OilEd [1])- In the cental of Nile, 
wc use this tool to generate a base oncology from the XML Schema 
provided by RosertaNet: each business object' class has a syntactic 
definit ion (its XML Schema type) and a semantic definition (its as- 
sociated DAML+OIL class). We can then tragment This ontology 
with additional constraint*. 

We present an overview of the mapping from XML Schema to 
DAML+OIL in figure 1. An exhaustive discussion on this mapping 
is out scope of this paper. 

The following is an example of taken from PIP3C3 [16] which Is 
a notification of Invoice process- Fmm the PIP3CXJ?inAncialDociiTne7it 
XML Schema complex type (see figure 2), the following DAML+OIL 
is automatically generated 1 : 

FijixxTiciclDocumcrii CI 
> 1 livjelicrns 

2 In the remainder of this document, we will use the Descriptwrt 
Logic notation instead of the DAML+OIL syiruw as ir allows for 
more concise expressions, 
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^^^=1^ *-W«= -ed » cap^ C a_»*i»±- I-i- invoiced 

«. y jc^ £ ext cue ±axi> 
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Fienre 2= An example of XML Schema PIP deflmticm 



l r The root schema element, compl^tType definitions, 
' mo dc\ group definitions and amibirteGroirp definitions arc 
mapped to DAML+OIL classes. 

2 Named 'simplcType' definitions stay untouched; anonym- 
ous sirnplciype definitions arc assigned a unique name and 
copied to a separate datatype file. 

. 3 Complex type elements arc mapped to DAML+OIL object 
' properte*; simple type elements and attributes m mappe d t*> 
DAML+OIL and attributes are mapped to HaML+OIL data- 
type properties! 

4 TVpc and occurrence specifiers of elements and attributes arc 
" mapped to an intersection of DAML+OIL property type and 
cardinality restrictions. 

5. Eaieasions and restrictions arc mapped to a. DAML+OIL 
subQass relarionsnip. 

6. Groups with & 'choice' cornpowW are mapped 
DAML+OIL disjomtlJoionOf collection. 

7. Groups with an *all' e> 'sequence* composi*OT are mapped to 
a DAML+OIL mtersectionOf collection- 
s'. Sub^timtionGraiip relationships are 

DAML+OIL subPropcrty relationship 

9. Names d! component* are always mapped to an IIRI com- 
posed of the schema taxBeiNarnespane, *#* and the compon- 
ent's name, 



Figure Is XML Schema to DAML+OIL Mapping 

It is now possible to express constraints of a semantic nature on 
business objects such as PIPZC^inaruaaXDocmnerd- 

3.2 The Constraint Knowledge Base 

We have identified in section 2 that a constraint on a business 
object depends on its deployment contort. A deployment context is 
characterised by: thft particular PIP document the business object 
it appears in, the buyer and seller trading partora and to tasincss 
process used. 

We define a simple ontology winch models the deployment con- 
texts in which a. constraint can apply. We create 3 DAML+OIL — > 7 - * ZZZ.~^7„nAMT +oru W= have sucoess- 
*in«« Document P art™*- and Process, and 4p*opflities docixmcntJDCL and can all be represented id DAML+OIL w= i^c sacoess- 

cusses, j^ocumeTU, rBr^ ^ j » *~ ^i™™. r..iiv ncpri cVTRd 111 to model these constrainis m DAML+OIL. 

buyer, setter and -process. The deployment context ontology fully used UJ m mooci mux wu* 



is populated wim subclasses and instance* of the 3 classes men- 
lionnod above. For example, is an instance of Document, 

EvropeanParlncr is a subclass of Partner. 

Context = V documG-nt-Documeni n 

V foyer-Partner n 

V ictfer-Partner n 

V process. P roces* 

A deployment context is created by subclassing the Content 
class and adding restrictions on one or mare of the &ur properties, 
allowing the specification of restricted contexts. For example, the 
h^ycr properry can be restricted to have the sub-class European? or trier, 
to allow the dcftnb'on of a constraint which applies to all European 
Buyers. 

To represent constraints, we also create the Constraint class 
imd the inCcmtext properly 

Constraint = V inContext-Context 
A constraint on class C in context Cfcc is defined as feilowr 

CnV inContext-Gtr C ... 

As an example, the constraint that restricts the class PIP^C^JFinandaXD 
in context Ctx to b*ve ar most 10 Un±Items clcmente and at least 
1 aoldTo elements could be written: 

PJP3C3JFina7iaalDocumen* n V inContext.Ctx rz 
< ID lineltem* n 3 soldTo 

We now give a more complex example constraining the class 
prPSCZ^inaricialDoGUTnent in content Cite: ifthc PIP3C3-Pinancxa 
instance has any linelte™* elements, these line/terns elements 
must have at Least <me totalTATielt&mAmouTii elem ent . This i* 
expressed as follow: 

PIPZCZJ^iruinciaiDaciirncTit H V inCtmtext.Gtx C 
V Uncltcms. (3 tQialLineltemATTicnmt ) 

As an experiment RosctiaNet has been using OCL to represent 
semantic confitfainis on PIP document specifications. Our study of 
these specifications show that these c Distraints only use a sub set of 
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DAML+OflL is a very powerful cnTology Iw^fie but also_ » 
quite complex fomon^rt^ rf^o] of thcK^ 
ConstiBint Editor is id hide this complexity from the llosettatfct 
implement**. An analysis of ItosettaNet deployments Has been 
carried oik to determine *c lands of constninx cxrnimonjy applied 
to documents by busiaesses, and 3 key classes have been identified. 
Hen? ^6 present templates for each class, together with an. example 
coamaini: of ihat class, 

1 Cardinality constraints: because of the diversity of deploy- 
ment scenarios, the RcsetraNet specification may leave a lot 
of flcxMrry for ills carnality of some fields (for instance 
0..oo)» However, specific deployment contexts mzy impose 
more constrained cardinalities. 

To restrict the m^imuro cardinality of lineltems ti? 10 on 
all Invoice classes in context Ctx s the tool generates the 
following statement: 



1. Create an RDF resource reprcscniinE the XML decamcnt. 

2. Add an rdf : type property to the RDF resource. Its v*lue 
is the URI or the DAML+OIL class concspotimng to the 
XML Schema type of the XML element. 

3. Each sub-elemrmtt and attributes are translated to RDF prop- 
erties on this RDf resource, 

4 If am element is a lc*r node (i.e. it conrains dala), mc data, 
is represented as an RDF literal on this property. Other- 
wise if an clement contains attributes and/or sub-elements, 
it is iransfbrmed to an anonymous resource wHth becomes 
the vafce of the respective property and which ts recovery 
rran&rarnaed starring at siep 2, 



Figure 3; XML to JtDV Mapping 



Invoice □ V in.Contc'j*.Ctx £ < 10 line Items 

2. Data format constraints: for the same reasons, the format of 
" some data needs to be restrained. Common examples in- 
clude rhe size of a string or tim format of a date, b DAML+OIL 
lenns, a datatype properly needs to have a more msiHcted 
XML Schema type. The twl generates a restricted XML 
Schema type and ccaistmiors the datatype property tn this 
newly defined type. 

3. imerdependency of fields: the presence ofa field, w the value 
" c-fa field, may imply a cardinality corumraint of a 4^ format 

constrami. 

3.3 Validation and inferencing on XML docu- 
ment 

At design time, one can use the XML Schema to DAML+OIL 
mapping tool to create a skeleton ontology. One can also extend or 
refine this generated ontology. At runtime, whan XML documents 
are being processed, one would like ro perform validator, and/or 
inferencing on these instance documents based on the extended on- 
tology. 

The idea is to have a 2-phase validatJpn process: 

» validation or the syntax of an incoming oocoment according 
to an XML Schema with a validating XML partem 

• validation of the semantic cmiatraints according with a de- 
scription Lo£*£ reasoncx. 

In order to validate the syntax, we need to generate an XML 
Schema that conveys all the syntactic restrictions, i-e_ the data 
format constraints, that have been added in the knowledge Use. 
This new XML Schema is almost identical to the original one that 
was ropnred in the system: the only difference is thai some simple 
types are now more restrictive since they have been constrained by 
various facets (formBtance, length, regular expression ormaxiinwi 
■value). 

DAML+OIL rcasoners are meant to do inference on RDF data- 
Since XML and RDF have diHerent modeling foundation, we have 
developed a tool that translates XML documents to RDF data so 
that they can be processed by a DAML+OIL reasoner. This tool 
outputs an XML iree model to an RDF directed geanh representa- 
tion, and since a tree is a specialization of a graph this is always 
possible. Also the tool assumes that the XML documents validate 



an XML Schema. This is an important consideration as it allows a 
generic mapping. We give an overview of the mapping in figure 3 
but a detailed explanation of the mapping is out of scope of this 
paper. 

3.4 Implementation Details 

4. USING NILE 

The NILE tool can be used to commission a new B2B partner- 
ship and tomanagean existing one. Here we present the stages this 
process goes through, and show how Ntt-B is used al each stage- 

1. For a Dfe*> relationship to be Set up between two partners, 
they must first identify the appropriate PIPs and associated 
documents which will he tiarrsferred. Given this (assum- 
ing the FTP is next-generation), they will have access to the 
RoscttaNet XML Schema templates for the dDcumcnis- The 
XML Schema are loaded into the Nile CUmstrairrt "E ditnr and 
Eiuiomatically translated into aDAML-rOIL knowledge base- 
ftsr instance to ser up a relationship involving PIP3C3, the 
HP3C3 XML Schema (and the other 4 imported XML Schemas} 
need to be loaded in the Nim Constraint Editor. If a business 
has already used this PIP with another partner, appropriate 
inforrnirion will already appear in their knowledge base, so 
they can skip this stage. 

2. The partners augment the set of constraints with personal 
constraints which are imposed by their internal busings pro- 
cesses and the specifies of the relationship they are trying 
to set up. These should represent constramts which would 
require business re-engineering to alter, not simply prefer- 
ences. Legacy systems often impose hard canscraints that 
cannot be altered. Previously entered coristraints that are 
compatible with the current deployment context are automat- 
ically irmerrted. 

3. When bath partners have prepared their ccnmaiirrs, they cm 
determine if their processes arc potentially compatible. They 
do this by sharing coristraints, and determining if the union 
of both constraint sots are satisfiable- A DL masoner, such 
as Fact or Racer, is used to verily this. Tb'n can either be 
done by a third party, or by one or both of the partners. If 
the constraints arc not sarisfiablc, it means there is a funda- 
mental mismatch between the two business processes, and 
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Figure 4: The Nile Constraint Bttitor 

r^ginc^g^llbeTcqiiirBd to thieve comp^biiity. 1^ 
t*ro partners will need to cnttf into off-line negations to 
determine boiy to handle this- When one °r *f th Paitaers 
have filtered vueir business paces*, they should their 
ctmstra-inis to reflect this, and return to stage 1- If the con- 
straints ai« s«isnable, the intersection of the two defines a 
subclass of the document definition which is acceptable to 
uoth parde9-[**&G**] This is used as input to the next stage- 




fflHi 




Specific | 

XWL Schema ! 



! Specific ] 

Idaml+OIL Ontoln gyl 

EcminUt CniuJitlrU 
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Figure S: Deploying * PIP in a erven context 

4 E*ehparmer now needs to wfiimilate the oth=- partner's coca- 
" Boaktsmio their consort kr^lei^c b^e. Obvioosry^tney 
do not wnt to apply these consnaiiits every time they send 
a docpinetw ofthis type, but only in the appropri** context 
The least general way of doing this is 10 appl/ a new con- 
straint prdy when sending a specific document to this spe- 
cific partner, hi the context of this PIP- This approach would 
watt and generation of the appropriate constramU could 
be straic^tfbTwftfdly automated- However, doing this lo*es 
some knowledge which is captured during the constraint geo.- 
Eration process. Of^\, a con snaint applies to * feature oftnc 
business process which may appear in many ilociimcnts and 
many PTPs To encourage maintomabuity and re-usability, it 



is best to General* a single w""*" " -*•* " 

Ren ^U cLact. [**EG«] The confab may even go bey- 
L thespecific tradingpartner. 51 there a*; - «*J ^ of 
p^merswbich all need similar constraints. ["EG ]Cur- 
ready, this eeneraUsation of constraints is earned, out by the 
developers. 

pla4 fcTll documents which will be exchange* bgdto 
L« inflate* are DAMLKIWL classes genentnd^- 
plyins th7 const™* knowledge b^e m the specific eontoa 
tfZ relationship- ["EG"] These "^££22 
ted on a 'best effort' basis via mc fc«asl^oa smto ^° XML 
Sch^ 3 . f*EG«J Any constraints in DAML/OWL which 

^ tepresected * *c Schema Ibnnat wfll be output 
comments within the sdinma.[**EG"*l 

6. BevelopersweContiv^tosertherwilh thc XML Schema,* 
enabtegmeiaUoD oT documents atruniime an required by the 
execution of a FTP. 

Optionally, runtime validation can be carried eu<- When an 
XML document is generated by mc Coimvo tool, NILE can 
check that it do=fi indeed satisfy the constraints ™ itht Know- 
ledce Base. It docs this by using the translation tool to con- 
vertthc XML document into an BDP represents**,*, and us- 
ing a DAML nastier sueh as FACT OX RACE*, to check 
■hat the RDF structure is indo=d an instance of the reared 
DAML class. t*'Ee??T] 



7. 



I speemc ' 
j XML Schema j j BAM L+OIL ontology? 




Fi E urt 6: The Nile System at rnirriinc 

In this way, developers can use NILE in conjunct with exist- 
ing products to rapidly setup new RoseuaNet relationships. 

5. RELATED WORK. 

6. CONCLUSIONS AND FUTURE WORK 

The NILE tool allow developers to explicitly represent the con- 
straints on interactions in diflfcitnt contexts and lore-use constraints 
between merges and businesses. This mates ^J^=f. 0 ^ 
ting up new TtdLionships fcstc and the rcsulUng .-.oftware is more 
reliable and re-usable. 
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The appi^ach we have taken is evplittirmary, in that it accepts 
RosetiaK^t in its current form. However, we believe that our ex- 
periences can provide valuable input into t^ure cn^^^ts of 
RosettaNeL In particular^ we believe that ji should adopt IX^VM^OWL 
as the constraint language to formally specify PE> message*. The 
increased expressivity will avoid unnec^ary ambiguity m the ap±- 
cificHiion, FunhcrmDic, it w" allow new tools to be developed 
which support business interactioriby reasoning with the coiistrauics. 

We have developed a suite of toolsto allow the use of DAML+OTL 
rich semantic modeling features in XML documents and their as- 
sociated XML Schema*. While these lools have, their origin in the 
Kile system, we believe ihem to be generic and thmk they could be 
applied to o4>er situations. 
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